
Configuring server Smalltalk )ay " 


I n the past. I’ve described major functional and perfor¬ 
mance differences between client Smalltalk and server 
Smalltalk. The client Smalltalk virtual machine oper¬ 
ates as a single process that manages objects in virtual 
memory. Server Smalltalk, on the other hand, operates 
in a multi-process architecture where the domain of 
objects can extend beyond the range of virtual memory. 
Server Smalltalk must coordinate the creation, synchro¬ 
nization, and termination of multiple processes that per¬ 
form such tasks as: execute a user’s Smalltalk code, per¬ 
form background garbage col lection, coordinate multiple 
users transaction activity, serve disk 
pages to clients across a network, 
and manage shared page caches. To 
provide the needed performance, 
server Smalltalk is implemented to 
take advantage of the features of 
server-class machines, such as 
shared memory, asynchronous 10, raw disk partitions, 
and SM P CPU configurations 

Obviously, configuring and tuning multi-user, server 
Smalltalk systems is very different from tuning single- 
user, client Smalltalk applications. In client Smalltalk 
applications, the main considerations when tuning are 
execution speed, runtime memory footprint, and image 
size. When tuning server Smalltalk systems, additional 
considerations are system-wide transaction throughput, 
amount of data transfer to clients, and disk 10 rates. The 
design of the overall system configuration must consider 
different hardware and operating system parameters, 
such as the amount of swap space, file system buffers, 
availability of raw disk partitions, the number of sema¬ 
phores, or the amount of shared memory. 

Due to the multi process nature of server Smal Ital k, sys¬ 
tem designers have a number of options when configuring 
applications to run in a client/server environment. One 
configuration option is deciding where to execute the 
behavior of server objects. Each session that is logged into 
the server has its own virtual machine process to execute 
server object behavior. Therefore, applications can be con¬ 
figured to create that process on whatever machine it 
wants. One option is to link the session into the same 
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process as the client vi rtual machi ne. This means that both 
virtual machines are executing within the same virtual 
memory address space. 

Another option is to have the session reside in its own 
separate process, and communicate with the client 
Smalltalk through remote procedure calls This allows a 
system designer to configure the system so that some ses¬ 
sion processes reside on client machines, some on the 
server machine, and others on a third machine. Note that 
none of these configuration choices impact application 
code. Application code does not need to know where the 
execution of server object behavior 
takes place, and the configuration 
can be changed with no modifica¬ 
tions to application code. 

Figures 1—3 illustrate some possi¬ 
ble configurations for the location 
of the session processes. In Figure 
1, a si nglesession process is I i nked with theclient process. 
This makes for fast repl ication of server objects i n the cli¬ 
ent Smalltalk, but might cause much data transfer over 
the network when many server objects are read or written. 
In Figure 2, the session process is separate and resides 
on the same machine as the client Smalltalk. This con¬ 
figuration enforces data integrity because server objects 
and client objects reside in different virtual memory ad¬ 
dress spaces. If a bug in theclient application should cause 
random memory locations to be written with bad data 
(sometimes called "wild stores”), the server objects are 
protected by operating system features that prevent one 
process from writing over another. Depending upon the 
application,thisconfigurationmightsufferfromtoomuch 
data transfer over the network as wel I. 

In Figure 3, multiple session processes reside on the 
same server machine. One client application has a sin¬ 
gle session logged into the object server, while the oth¬ 
ers have multiple 
sessions logged in. 

This configuration 
enforces data in¬ 
tegrity also, and 
data access is faster 
since the session 
processes are on 
the same machine 
where the disks re- 
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Figure 1. Server and client virtual 
machines linked. 
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side. The key advan¬ 
tage of this configu¬ 
ration is that many 
sessionscan takead- 
vantage of a shared 
page cache of ser¬ 
ver objects. In most 
applications, a large 
percentage of ob¬ 
jects are read only, 
and fewer are actu- 
allywritten. In many 
cases, multipleusers 
arereadingtheiden- 
tical objects. Classes 
and methods are prime examples of objects that are read 
only during normal application execution. When multiple 
sessionscan shareobjects i n theshared pagecache, itsaves 
space and decreases access time, since common objects 
remain in the cache. A shared page cache can exist on oth¬ 
er machines as well;ashared pagecachecan becreated on 
anymachinewhereasession processisto execute. In gen¬ 
eral, itisgoodpracticetocreateashared pagecacheon any 
machine where more than one machine will execute. 

There are a number of parameters to tweak when con- 
figuring the multiple processes that make up server 
Smalltalk. The three main kinds of processes in which to 
configure memory requirements are the server process, the 
shared page cache and its monitori ng process, and the ses¬ 
sion processes. For each kind of process, various statistics 
are available to monitor and observe the effects of chang¬ 
ing configuration parameters In GemStone, you can get 
statistics about various processes that make up the system 
by executing the expression "SystemcacheStatistics:aProcess 
Slot". This message returns an array of information accord¬ 
ing to the kind of process bei ng described. To get a descri p- 
tion of each element in the array, you can execute "System 
cacheStatisticsDescription". For statistics gathering purposes, 
each process is assigned a process slot, and a process exe- 
cuti ng Smal Ital k code can get its own process slot by send¬ 
ing System myCacheProcessSlot. Among the information that 
you can retrieve for every kind of process is its process 
name, process ID, session ID, page reads and writes, and 
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Figure 3. Server virtual machines sharing pages. 


cache hits and misses. For the remainder of this column 
I will discuss the configuration parameters of the three 
main kinds of processes and describe the relevant cache 
statistics for tuning performance. 

The server process has a number of responsibilities, 
including synchronizing the transactions of the clients, 
arbitrating the locking of objects, and allocating object 
identifiers for clients to use when creating new objects. 
As the server allocates resources such as transaction rec¬ 
ords, locks, or object identifiers to each session, it stores 
this information in its private pagecache. The size of this 
private page cache should be adjusted according to the 
number of sessions that are typically logged into the serv¬ 
er most of the time. If the server’s private page cache is 
filled up, then it overflows into the shared-page cache, 
affecti ng the performance of other sessions. 

There are a number of statistics that help measure sys¬ 
tem throughput. For the server process, one can look at 
the#TotalCommits statistic to get the total number of trans¬ 
actions committed since the server process started. This 
can be used to measure systemwide transaction through¬ 
put. Another relevant statistic is the #NumberOfCommit 
Records. This is the number of outstanding transaction 
records that are currently being maintained by the server 
process. A large number could mean that there is a long- 
lived transaction that is preventing the server from re¬ 
claiming resources allocated for sessions created later. 

The shared-page cache i s where mu Iti pi e sessi ons share 
pages of objects. When a session process needs to access 
an object, it first checks to see if the page containing that 
object isalreadyinthecache. If so, itreadsthepagedirectly 
fromshared memory. lfthepageisnotpresent,theprocess 
reads it from the disk into the cache, where it becomes 
availableto other processes. When configuringtheshared- 
page cache, a system designer considers the total size of 
the object repository, as well as the number of sessions 
that will utilize the shared pagecache simultaneously. 

There area number of statisticsonecan lookattomon- 
itorthe activity of theshared pagecache. One statistic that 
provides some indication of the utilization of the cache 
is the #NumberOfFreeFrames. This is the number of unused 
page frames in the shared page cache. Another statistic, 
#SharedAttached, isthe number of pages that are bei ng uti¬ 
lized by more than one process. This indicates the amount 
of shari ng i n thecache. When pages i n theshared cache are 
written, they are scheduled to be written to disk when the 
transaction commits. The statistic #GlobalDirtyPage Count 
gives the number of pages in the shared cache that have 
been modified, but are not eligible for writing to disk be¬ 
cause they have not been committed yet. If this value is 
I arge, then I arge transacti ons that wri te a I ot of obj ects may 
be taki ng u p space i n the cache, or the server’s pri vate page 
cache may be too smal I (so it is using theshared pagecache 
for the overflow). This statistic can be compared against 
#LocalDi rtyPageCount, which is the total number of pages 
that have been modified and are el igiblefor writing to disk. 

As descri bed earlier, each session executes the behavior 
of server objects with its own continued on page28 
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decide, 'Why don't we use something less complicated, 

I ike C++.'" 

The study STIC released last year found that compa¬ 
nies adopting Smalltalk were more likely to have followed 
a formal process in choosing a programming language. "If 
we can get people to do real comparisons, then Smalltalk 
has a significant advantage," Phillips concluded. 
"Smal Ital k seems to have to fight its way i nto an organiza¬ 
tion, but once its there, it does pretty well." Smalltalk pro¬ 
jects also were twice as likely to achieve their expected 
goals "The Smalltalk industry has the opportunity to 
grow and prosper be cause of the successes that are there. 
It'sa matter of getting the word out," Phillips said. 

To Adele Goldberg, the issue is not just teaching 
Smalltalk, but teaching systems building as opposed to 
programming. "Too many university computer science 
curriculums stop at teaching data structures and algo¬ 
rithms," she said. It's not surprising it so hard to recruit 
people capable of building extensible, adaptable sys¬ 
tems. "The most significant part about a system is that 
once we start it up, there’s a maintenance issue. You want 
it to run indefinitely." And while people can learn the 
syntax for programming in Smalltalk in an afternoon, 
"they don't get the systems building part," Goldberg said. 

Her solution is LearningWorks, a modified version of 
the Smalltalk implementations she used to teach pro¬ 
gramming to 12-year-olds Its interface is organized into 


a neat binder of several "books" used for system plan¬ 
ning, experimentation, and development, and it feeds 
students the modern Smalltalk class library a little at a 
time. Using the internet as a medium for distributing 
thisfree tool, she plansto have Open University students 
collaborate on building LearningWorks systems as class 
projects 

Students can start by experimenting with rehearsal 
worlds that illustrate key concepts and provide a context 
for exercises in organizing behaviors and allocating re¬ 
sponsibilities, Goldberg said. Businessescould train their 
employees by having them create LearningWorks books 
that represent the essence of the company's framework. 

Reg Krock of the Ontario manufacturing firm Maksteel 
wasoneofthepeoplewho approached Goldberg after her 
talk to express interest in obtaining a copy of Learn¬ 
ingWorks. "One reason is that we have a 67-year-old pres¬ 
ident of our company. I could give that to him, and he 
would actually play with it." 

Computer systems are theonly part of the busi ness that 
M aksteel's presi dent doesn’t fu 11 yu nderstand, wh i ch makes 
it harder for him to manage, Krock said. "There’s always 
been a language gap between the CEO and the CIO. What 
I’d like to do is take some of the mystique out of it." K 
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continued from page22 

virtual machine. Each session process has two caches in 
which to access objects, in addition to the shared page 
cache. One cache, called the temporary object cache, is 
where new objects are created. As the execution of server 
Smalltalk code causes new objects to be created, they are 
created in a section of memory carved out just for that 
purpose. This area of memory is garbage collected by gen¬ 
erational scavengingtechniques, since many newly creat¬ 
ed objects die early and can be garbage collected soon 
after their creation. If this cache should become full, then 
some objects from it must be written to disk, where gar¬ 
bage collection is more expensive. To determine the ap¬ 
pro p ri ate si ze for the tern porary obj ect cac he, a system d e- 
signer must consider the total size of all new objects 
created during a single transaction. 

The other cache utilized by the session is the private 
page cache. This cache is a private area in which to read 
and write pages of objects. This cache isusually small, si nee 
the session primarily uses the shared page cache to read 
and write objects. If the system isconfigured not to allocate 
a shared page cache on the machine where a particular ses¬ 
sion is executing, then its private page cache size should be 
increased accordingly. 

A session’s process can get a variety of information 
about itself. To monitor garbage collection activity in 
the temporary object cache, a session can get the #Time 


I nScavenges statistic to find out the CPU time spent per¬ 
forming in-memory garbage collection, #NumberOf 
Scavenges to fi nd out the number of ti mes the i n- memory 
garbage collector has been executed, or #NumberOfMake 
RoomlnOld Spacetofindoutthenumberoftimestheoldest 
generational spacefilled up (a large number may indicate 
that thesession’stem porary object cachesizeistoo small). 
A session can also find out how well it is using the shared 
page cache. Itcan getthe#NumberAttached statistic to find 
outthe number of pages that the process iscurrently using 
in the shared page cache, and #LocalPageCacheHits and 
#LocalPageCache Misses to find out how manytimesa page 
was found or not in either the shared page cache or the 
private pagecache. A session can measure its transaction 
activity by looking at the #NewObjs Committed statistic to 
find outthe number of newly created objects committed 
bythemostrecenttransaction,and#NumberOfCommitsand 
#NumberOfFailed Commits to get a cumulative number of 
successful orfailed transactions si ncethesession began. 

The statistics descri bed above are but a sampl i ng of the 
kinds of information to look at when configuring a multi¬ 
user Smal Ital k system. The key to successful ly confi gu ri ng 
and tuning such systems is understanding the multi¬ 
process nature of clients and servers, and how different 
memory spaces and caches are used. Fortunately, tools 
are available to gather these statistics over long periods of 
time and then graph the results to analyze overall system 
performance. Without the abi lity to gather statistics about 
each process in system, tuning is a shot in thedark. ffl 
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